The disclosure relates to methods and apparatus for providing secure communications among devices such as constrained devices in a network.
In proposed models for providing security for the Internet of Things, there are two proposed authentication infrastructures, either or both of which may use public key infrastructure (PKI) technology and certificates. For example, when connecting multiple devices to a network (or to each other), via the Internet, a first security infrastructure may install credentials in the devices that uniquely identify each device. These identification credentials may be unmanaged from a security perspective and are independent of the domain of use. For example, when a device that can be connected to a network is manufactured, such as temperature sensors and thermostats to be installed in multiple floors of a large building, the manufacturer may have a server or use a server of a third party as a root certificate server and generate identification certificates for each of the devices that are produced by the manufacturer. As such, during manufacture, a database may be created with an entry correlating a unique identifier of the device with a certificate that is signed by the root certificate authority. In this manner, when a device is turned on, it may authenticate via a network, to the root authority or to another certification authority.
However, a different security infrastructure may be used for managing the configuration of the device when it is installed. As such, generic devices need to be added as new devices in a system or network and then the device needs to be configured to operate in a particular manner consistent with the needs of the system or network. For example, another authorization infrastructure may be used for managing authorization such as which devices are authorized on a network, which devices are authorized to communication with certain other devices, which devices can send which commands to which interfaces of which other devices in a network and their configuration settings. With a growing number of devices having to be installed in larger networks such as building networks, roadside infrastructures, manufacturing facilities, and other environments, each device is enrolled in a database of the second infrastructure.
As cryptanalytic capabilities advance, and certain cryptographic algorithms cease to be adequately secure for their purpose, it is necessary to continuously update the cryptographic algorithms and keys in use, while continuing to support parts of the network that have yet to update their algorithms. This presents a problem because both parties to a communication must use the same algorithm, yet it is impractical to update all devices 102-102n simultaneously. This problem is usually solved by supporting a range of algorithms in devices that accept connections and messages, even obsolete ones. Devices that originate connections and messages must only support any one of the algorithms supported by the other parties with which it communicates. The cost paid for this solution is that all parties that accept connections and messages must support multiple algorithms and have keys suitable for use with each. In a network of constrained devices this cost may be unacceptable. A constrained device as used herein is one that stores one cryptographic algorithm code module per cryptographic function in memory. A code module as used herein is stored executable instructions that when executed by one or more processors, causes the one or more processors to perform operations as dictated by the stored instructions of the code module.
Referring to FIG. 1, a system 100 is shown with a plurality of devices 102 and 102n, that are to be added in a network, such as a network that employs the Internet 104. The devices may be sensors, actuators, roadside infrastructure elements, or any other suitable device that can network with the Internet or other network. Enrolling the devices 102-102n may be typically done in a batch process at a central location and then shipped to be installed. An administrator would need to review a plan of an overall system and try to figure out how to configure the devices.
In this example, a security management device 106 or authorization server that is part of a security management infrastructure, in this case a PKI infrastructure, populates a database 108, through an administrator interface at a server or other computer as part of the device 106, with data needed to issue device configuration certificates that are then issued to the devices 102-102n to configure the devices to operate as required by the network. Networks of sensors and actuators may use the authorization server that controls the privileges of the devices of which the network is formed; dictating which devices are permitted to access which functions on which other devices.
Each device has a suitable network interface to communicate with the network and with each other, and in this example, includes an IP address or URL. In one example, the security management device 106 may generate device configuration certificates in a capability certificate model shown as certificate 110 and/or device configuration certificates based on a device permission certificate model, shown as certificate 112. The device configuration certificates may be stored in a certificate database 114 as known in the art. An example of a device configuration certificate based on a capability certificate model would be a certificate, for example, signed by the security management device 106 or other suitable certification authority. The device configuration certificate that is based on a device capability certificate would include, for example, the device ID, such as a serial number, IP address, URL or other identifier, as well as data representing the commands the particular device can emit and which devices are authorized to communicate with other devices in the network. A device configuration certificate that is based on a device permission certificate 112 through a permission model may generate a certificate that includes the same type of device ID information and data identifying what commands a device can accept. The database 108 may include, for example, the device ID for each device in the network and a per device location such as the position of the device within the system. For example if the device is a sensor in a one of many pipes, its position within a particular pipe with respect to a particular junction of pipes or other location information has to be determined by an administrator. The database 108 may also include other device information such as the model number and serial number of the device as well as capabilities of the device set by an administrator that may set the parameters through a suitable user interface of the security management device 106. Alternatively, permissions or rules may be stored for a particular set of devices if a permission model is used. The issued device configuration certificates, whether they be based on a capability model or permission model, after generated or issued, are then sent to each respective device so that their configuration is securely administered through a public key infrastructure based security system. As such, a device 102-102n, will only accept a certificate if it can verify that it was signed by a trusted root authority, and changes can only be made to the configuration of the device via the security management device 106.
There is a need for systems that employ constrained devices to maintain secure communication around the devices.